home *** CD-ROM | disk | FTP | other *** search
/ HaCKeRz Kr0nlcKLeZ 1 / HaCKeRz Kr0nlcKLeZ.iso / chibacity / 40hex-6.arj / 40HEX-6.002 < prev    next >
Encoding:
Text File  |  1992-04-08  |  7.9 KB  |  153 lines
  1. 40HEX_6_002     SEGMENT PUBLIC 'code'
  2.                 ORG 100H
  3.                 ASSUME CS:CODE,DS:CODE,SS:CODE,ES:CODE
  4.  
  5. ;******************************************************************************
  6.  
  7. Concealment:      Keep Your Code Hidden From Prying Eyes
  8.                                         by Demogorgon/PHALCON/SKISM
  9.  
  10.  
  11.      Recently, I have been experimenting with a few new programming techniques
  12. that should be of great interest to the virus writing community.  It is always
  13. our top priority to keep our code out of the hands of lamers in order to
  14. prevent the dreaded 'text change' and above all, to cause the anti-virus
  15. community as much grief as possible.  In order to do this, we must put a great
  16. deal of effort into concealing our code.  That is the focus of this article.
  17.  
  18. This file is divided into two parts.  The first part is devoted to developing
  19. 'debug resistant' code, and the second part deals with defeating disassemblers.
  20. I will not cover encryption, because methods of encryption are commonly known
  21. and there is really not much further I can go with that.  For a complete review
  22. of self encryption methods, take a look at Dark Angel's Funky Virus Writing
  23. Guide (number three, the one that hasn't been released yet.)
  24.  
  25. Part_I: The debugger is NOT your friend
  26.  
  27.      The basic idea behind writing debug ressistant code is finding a way to
  28. make your code behave differently when it runs under a debugger.  With a real
  29. mode debugger, this is simplicity itself.  All that is necessary is a little
  30. knowledge of how a debugger works.  A debugger, such as debug or TD traces
  31. through a program by setting handlers to int 1 and int 3.  These are called
  32. after every instruction is executed.  A virus that wishes to avoid being
  33. debugged can simply replace the handlers for these interrupts, and the results
  34. will be just about whatever you want.  Here is some code to do this:
  35.  
  36. eat_debug:
  37.         push    cs
  38.         pop     ds
  39.         mov     dx, offset eat_int
  40.         mov     ax,2501h
  41.         int     21h
  42.         mov     al,03h
  43.         int     21h
  44.         ...                     ; rest of code
  45. eat_int: iret
  46.  
  47.      As you can see, this requires minimal space in your code, and is certainly
  48. worth the effort.  You can experiment by placing something else at 'eat_int'.
  49. Another commonly used tactic is to disable the keyboard interrupt while certain
  50. parts of the code are being executed.  This will surely keep lamers baffled,
  51. though a pro would recognize what was going on immediately.  I am sure McAfee's
  52. programmer's scoff at code such as this.  Also note that while this will defeat
  53. the average real mode debugger, any protected mode debugger will step through
  54. this as if it weren't there.  Playing with interrupts will not help you when
  55. your program will be running in a virtual cpu anyway.  One method I found which
  56. will work nicely against td386 is to throw in a hlt instruction.  This will
  57. give TD an exception 13 error, and terminate the program.  Anyone who is aware
  58. of this will just step over a hlt instruction, so therefore methods must be
  59. used to conceal its presence, or to make it a necessary part of the code.  This
  60. will be covered in part II.
  61.      Another trick you can play is to call int3 within your program.  If
  62. someone tries to run your program under a debugger, it will stop each time int3
  63. is called.  It is possible to trace through it, but it will be annoying if
  64. there are many int3's thrown in.
  65.  
  66. Part_2: Kill your disassembler
  67.  
  68.      No matter how well you mess up debuggers, your program is entirely at the
  69. mercy of a programmer armed with a good disassembler.  Unless, of course, you
  70. use techniques that will confuse disassemblers.  My favorite method for
  71. baffling them is to create code that overlaps.  Overlapping code may seem a
  72. little bit too complicated for most of us at first, but with the knowledge of a
  73. few instruction hex translations, you too can make effective overlapping code
  74. without sacrificing too much code size.  Overlapping code can get as complex as
  75. you would like, but this file will only deal with the simplest examples.
  76.  
  77.  
  78. eat_sr: mov     ax,02EBh
  79.         jmp     $-2             ; huh?
  80.         ...             ; rest of code
  81.  
  82. This may confuse you at first, but it is fairly simple.  The first instruction
  83. moves a dummy value into ax.  The second instruction jmps into the value that
  84. was just moved into ax.  '02EB' translates into 'jmp $+2' (remember that words
  85. are stored in reverse).  This jump goes past the first jmp, and continues on
  86. with the code.  This will probably not be sufficient to defeat a good
  87. disassembler like Sourcer, but it does demonstrate the technique.  The problem
  88. with this is that Sourcer may or may not just pick up the code after commenting
  89. out the 'jmp $-2'.  It is difficult to predict how Sourcer will respond, and it
  90. usually depends on the bytes that appear directly after the jmp.  To severely
  91. baffle Sourcer, it is necessary to do some stranger things.  Take a look at
  92. this example.
  93.  
  94. erp:    mov     ax,0FE05h
  95.         jmp     $-2h
  96.         add     ah,03Bh
  97.         ...                     ; rest of code
  98.  
  99. This code is quite a bit more useful than the previous listing.  Let us
  100. simulate what would happen if we were to trace through this code, showing a hex
  101. dump at each step to clarify things.
  102.  
  103.  B8 05 FE EB FC 80 C4 3B   mov     ax,0FE05h       ; ax=FE05h
  104.  ^^ ^^ ^^
  105.  B8 05 FE EB FC 80 C4 3B   jmp     $-2             ; jmp into '05 FE'
  106.           ^^ ^^
  107.  B8 05 FE EB FC 80 C4 3B   add     ax,0EBFEh       ; 05 is 'add ax'
  108.     ^^ ^^ ^^
  109.  B8 05 FE EB FC 80 C4 3B   cld                     ; a dummy instruction
  110.              ^^
  111.  B8 05 FE EB FC 80 C4 3B   add     ah,3Bh          ; ax=2503h
  112.                 ^^ ^^ ^^
  113.  
  114.      The add ah,03Bh is there simply to put the value 2503h into ax.  By adding
  115. five bytes (as opposed to simply using 'mov ax,2503h') this code will confuse
  116. disassemblers pretty well.  Even if the instructions are disassembled properly,
  117. the value of ax will not be known, so every int call after this point will not
  118. be commented properly, as long as you never move a value into ax.  You can
  119. conceal the value from the disassembler by using 'add ax' or 'sub ax' whenever
  120. possible.
  121.      If you examine this closely, you can see that any value can be put into
  122. ax.  Two of the values can be changed to whatever you want, namely the FE in
  123. the first line, and the 3B in the last line.  It is helpful to debug through
  124. this chunk of code to determine what values should be placed here in order to
  125. make ax what you would like it to be.
  126.      Back to the subject of killing debuggers, it is very sneaky to hide
  127. something like a hlt instruction inside another instruction, such as a jmp.
  128. For example, take a look at this:
  129.  
  130. glurb:  mov     cx,09EBh
  131.         mov     ax,0FE05h ;-\
  132.         jmp     $-2       ;  >--this should look familiar to you
  133.         add     ah,03Bh   ;-/
  134.         jmp     $-10
  135.         ...             ; rest of code
  136.  
  137. The three lines in the middle are a repeat of the previous example.  The
  138. important part of this code is the first line and the 'jmp $-10'.  What happens
  139. is, the jmp goes back into the 'mov cx' instruction.  The '09EB' translates
  140. into 'jmp $+9'.  This lands in the '$-10' part of the first jmp.  The $-10 just
  141. happens to be stored as 0F4h, the hlt instruction.  By making the hlt part of
  142. another instruction, it is not visible when it is being traced through by
  143. td386.  It is also not possible to remove it without altering the code.
  144.  
  145.      The purpose of this article is not to supply code to be thrown into your
  146. own programs.  The purpose is to get you to think about new ways to avoid
  147. having your code looked at and modified by others.  The most important thing is
  148. to be original.  It is pointless for you to simply duplicate this code, because
  149. anyone else who has read this file will already know what you are trying to do.
  150.  
  151. code            ENDS
  152.                 END     concealment
  153.